This invention relates to Quality of Service allocation on a network, for example on the Internet, or an intranet.
Conceptually, the Internet provides three sets of services. At the lowest level, a connectionless delivery system provides a foundation on which everything rests. At the next level, a reliable transport service provides a high level platform. At the third level, application services are provided which rely on the reliable transport service.
A fundamental Internet service consists of an unreliable, connectionless, best-effort, packet delivery system. The service is described as being "unreliable" because delivery is not guaranteed. A packet may be lost, duplicated, or delivered out of order, but the Internet will not detect such conditions, nor will it inform the sender or receiver. The service is described as being "connectionless" because each packet is treated independently from all others. A sequence of packets sent from one machine to another may travel over different paths, or some may be lost while others are delivered. The service may be described as "best-effort" because the Internet aims to deliver packets but does not guarantee delivery.
The protocol that defines the unreliable, connectionless, delivery mechanism is called the "Internet Protocol", and is usually referred to by its initials IP. IP defines the formal specification of data formats, including a basic unit of data transfer and the exact format of all data passing across the Internet. IP also includes rules which specify how packets should be processed and how errors should be handled. In particular, IP embodies the idea of unreliable delivery and packet routing.
Above the IP layer of the Internet protocol structure one service which is provided is a reliable transport service which is typically called the "reliable stream transport service", defined by the Transmission Control Protocol (TCP). The combination of the TCP protocol and the underlying Internet Protocol (IP) is often referred to as TCP/IP.
The reliable stream delivery service provided by the TCP can be contrasted with the unreliable datagram protocol (UDP) which is also provided over the Internet. The UDP provides an unreliable delivery service because delivery is not guaranteed. For example, packets may be lost or destroyed when transmission errors interfere with data, when network hardware fails, or when networks become too heavily loaded to accommodate the load presented.
The TCP on the other hand has a complex structure providing delivery by means of a stream of bits, divided into eight-bit bytes. The TCP specifies the format of the data and acknowledgements that two computers are to exchange to achieve reliable transfer, as well as the procedure to ensure that data arrives correctly.
As mentioned above, given that the underlying Internet protocol is unreliable, TCP transmissions operate in accordance with a technique known as positive acknowledgement with retransmission. The technique requires a recipient to communicate with the source, sending back an acknowledgement message every time it receives data. The sender keeps a record of each packet that it sends and waits for an acknowledgement before sending the next packet. The sender also starts a timer when it sends its packet and retransmits a packet if the timer expires before the acknowledgement arrives.
The period between the transmission of a message and the receipt of an acknowledgement is termed the Round-Trip-Time (RTT). The RTT varies over time depending upon many factors such as, for example, network loading (e.g., delays at intermediate nodes in the system) and loading on the receiver. An important factor in determining the RTT is the available bandwidth. Thus, where multiple clients have access to a common server, for example, in order to balance the Quality of Service between clients, it is desirable to control factors such as the bandwidth allocated to the individual clients, packet delay, and so on. The control of such factors is typically referred to as the control of a Quality of Service (QoS).
Currently, a QoS for specific information flows is allocated statically based on information contained in the traffic itself, such as IP source address, IP destination address, protocol and ports. The QoS is defined in terms of one or more configuration rules, each of which defines one or more factors, such as the bandwidth for an information flow, buffer sizes, firewall characteristics, etc.
The QoS allocation to an information flow is based on a unique identifier, which is usually constructed from parameters such as the source/destination IP address protocol, source/destination ports and/or any other relevant elements from the data flow. However, the QoS allocation to an information flow belonging to an entity is possible only if these parameters are tightly, and permanently bound to that entity.
Traditional QoS is essentially applied in a static manner. As well as providing limited flexibility, a static configuration has the effect that rules for the QoS may not be used if a user is not logged on to the network.
The Internet and similar intranets have been typically been based on a best effort, first-in-first-out basis. However, a trend to the provision instead of differentiated services over a network leads to a need for a more flexible approach to the allocation of a QoS.
However, there is the problem of how to achieve this. To create a configuration rule based simply on an IP address or a port as in the prior art is not effective where an entity to IP address or entity to port allocation can vary due to dynamic IP and/or port allocation. More generally, where there is dynamic allocation of a flow parameter (e.g., an IP address) to an entity, there is no tight link between the entity and the flow. It should be noted herein that the "entity" could be a user, or more generally could be an application, a piece of equipment or other network entity, and need not be a unitary entity, but could be a compound entity such as a group of users, a set of equipment, etc. Also, a dynamic flow parameter could be an IP address, a port, or any other dynamically allocatable flow parameter.
Particular reference is made hereinafter to dynamic address allocation, although it should be understood that the invention is not limited to environments with dynamic allocation of IP addresses, but also to other environments with, for example, dynamic allocation of ports. Dynamic address allocation is provided under a number of different environments. Examples of such environments are the Remote Authentication Dial in User Service (RADIUS) and the Dynamic Host Configuration Protocol (DHCP). A description of RADIUS is to be found in C Rigney, A Rubens, W Simpson, and S Willens, "Remote Authentication Dial in User Service (RADIUS)", RFC 2138, April 1997. A description of DHCP can be found in R. Droms "Dynamic Host Configuration Protocol", RFC-2131, March 1997.
In such an environment with dynamic allocation of IP parameters (e.g., dynamic IP address allocation), an entity will seek a presence on the network to establish an information flow, typically referred to simply as a "flow".
A conventional, static, approach to the allocation of QoS, with configuration rules (or policies) defining the QoS being established apriori, does not work efficiently, or at all in such an environment. At best, apriori allocation of QoS will result in inefficient use of network resources as the apriori allocation may not be applicable for a particular instance of an information flow. For example, due to bandwidth limitations of a predetermined QoS, a particular instance of an information flow may not be able to make full use of an available bandwidth. Also, in a network with a potentially huge number of entities, apriori installation of QoS will result in erroneous combinations of configuration rules with unused, or overloaded, resources. At worst, the apriori allocation will not work where there is no permanent link between a flow and an entity.
Accordingly, the invention seeks to provide a solution to the provision of a QoS definition for an environment in which dynamic allocation of flow parameters is practised.